The present invention relates to enhancement of appliance network efficiency, and more particularly, to a method and apparatus for enhancing appliance network efficiency of an appliance network having plenty service level monitoring (SLM) data.
Unlike general-purpose computer devices, an appliance is typically designed to serve a specific purpose or provide a specific service and thus is more robust. Compared with general-purpose computer devices, “appliances” are relatively “closed”—their specific operating systems and applications (or drivers) vary with their intended purposes and services.
An appliance, such as an access point, a digital TV set-top box, or a network file-sharing server, performs a specific transaction for serving a specific purpose. For sophisticated appliances, please refer to IBM® WebSphere® DataPower Series SOA Appliances or Tivoli® ISS Appliances® (“IBM,” “WebSphere,” and “Tivoli” are registered trademarks in the possession of International Business Machine in the United States and/or other countries).
In general, there is a certain degree of quality requirement of information services in terms of response time, throughput (TPS), etc. It is necessary that, once a threshold of a specified (that is, monitored) indicator is reached, the system infrastructure of an information service will have to provide a mechanism for measuring the current status and responding appropriately to thereby ensure the service quality expected by users. To allow messages to be received by and sent from a network, appliances (such as Datapower) implement a well-known service level monitoring (SLM) technique, which is usually implemented as an SLM strategy (policy) for use in monitoring major indicators to thereby assist a network administrator in identifying a problem instantly and giving an appropriate response.
According to the prior art, an appliance has an SLM module being executed to monitor the number of input messages received by the appliance and having a specific header and process the messages according to an instant sanction on SLM status synchronization. For example, the SLM module executes a specified action as soon as the quantity reaches a specified threshold. The specified action is queuing (or known as shaping), rejecting (or known as throttling), or passing (or known as notifying).
By synchronizing SLM statuses in a cluster formed by a plurality of appliances, an SLM strategy can be shared and implemented to process traffic of load balance of resources of the same target. A plurality of appliances in the same cluster (or known as peer group) has the same SLM strategy (or rule), and SLM data are shared by and between the appliances, thereby enabling exchange of SLM data between the appliances in the cluster. To synchronize SLM statuses of the appliances in the cluster, each appliance has to send its own SLM data to the other appliances. The SLM data can be sent by unicast or multicast.
However, in case of a high load, plenty of SLM data will have to be sent, thereby resulting in overwhelming traffic overhead and even network congestion. For the perspective of an SLM-based business-critical appliance, a trade-off between SLM reliability and network efficiency is likely to have a great impact on business.